The present invention relates in general to distributed computer systems having multiple clients and multiple servers which are dynamically coupled and decoupled as needed, and in particular to systems, methods and computer program products for dynamically generating fast client-side proxies given any type of service interface specification/definition document, such as IDL, WSDL or JMX Mbean descriptors, and the like.
In the now-popular and widely used client/server model of computing, a requesting program, called the client, often must make a request of a service-providing program, called a server. In a distributed computing environment, the server program is often located remotely on a computer network, and in such instances these requests are often called RPCs (Remote Procedure Calls). In the networks of larger enterprises, there are often one or more computers (also often called servers) dedicated to the role of servicing requests from a multitude of individual workstations and still other computers on the network. Such computer servers may include email servers, firewall servers, storage servers, application servers, database servers, web servers, and the like. Often times, there are a group of local computers, connected together on a LAN (Local Area Network) that can communicate or obtain data from still other computers connected through a WAN (Wide Area Network) or the Internet. In recent years, due to the explosive growth of the Internet, there has been a definite trend to making not only information in the form of web pages available at distant web sites over the Internet, but also making available the use of remotely located computer programs (called applications) over the Internet. Thus, many applications used by workstations or other user terminals are now found on remote servers. The present invention is directed toward improvements in the ways these RPCs are made, particularly in light of frequent changes or updates made to the capabilities of the server programs. To better explain the present invention, it is useful to review certain current practices.
Server computers, whether on a LAN, WAN or on a website, are designed to be used or accessed by many users concurrently. Each server typically has a multitude of programs on them, and often supports a multiplicity of different services. A small network installation may have all of its services and server programs on a single computer, while larger websites or enterprises may have them distributed among several computers or several LANs interconnected by a network or the Internet.
In a distributed computing environment, when the requesting program (the client) makes a request of a server program, it may suspend at least part of its operation until the results of the remote procedure call are returned. This in turn may precipitate still further calls on the local computer on which the client is located. The use of lightweight processes or threads that share the same address space within a computer or a tight cluster of computers on a network often allow multiple RPCs to be performed concurrently. Nonetheless, from both an administration viewpoint and a computer user's viewpoint, quickly fulfilling specific user requests is important, regardless of how many underlying RPCs had to be made by the local computer and/or remote server computer carry it out. In general, delays of more than a few seconds are generally not well received. Thus, having quick responses to RPCs is important, even as network and server traffic becomes heavy.
To accomplish an RPC, program statements must be executed on the requesting computer. When program statements that use RPC are compiled into an executable program, a “stub” is included in the compiled code that acts as the representative of the remote procedure code. When that program is run and the procedure call is issued, the stub receives the request and forwards it to a client runtime program in the local computer on which the client is located. The runtime program of the client has the knowledge of how to address the remote computer and the server application located thereon. It sends the appropriate messages across the network as may be required in order to request the desired procedure, which often is called a method. Thus, this act of a client requesting something is sometimes referred to as “method invocation.” When done remotely it is called Remote Method Invocation (RMI).
In a typical distributed computing environment, there is a need to update periodically various applications and user programs located on servers and the computers of end users due to software upgrades, increased security measures, network and/or operating system upgrades, reliability improvements, software patches, and the like. On a network, this task is made somewhat simpler by grouping together related applications and/or making them available in connection with or through a particular kind of installed “service.” These services are typically designed to facilitate seamless communications and interoperability of extended or enterprise networks. In larger networks in particular, there are often multiple services provided, such as CORBA (Common Object Request Broker Architecture) Service, WebService, and Java MBean Service, among others.
In a complex distributed computer environment, one approach to the task of upgrading applications and those client programs which use them, at least for those written using object-oriented programming, is to provide centrally located definitions for the various application programs which can be easily updated. These definitions typically are on a service-by-service basis and are called Service Interface Definition Documents (SIDDs). SIDDs specify various interface attributes, variables, arguments, class information or other parameters associated with accessing that service as implemented on the server system. The SIDDs may be stored for access by clients in an interface repository which is typically a secure location on a server.
By accessing and making use of these interface definitions, particularly after they are updated to reflect improved functionality or capabilities for the application, classes or objects referenced thereby, the client programs which call or invoke these services and their applications can have the benefit of the latest updates. The present invention is concerned with the specific processes and limitations associated with these updated SIDDs, particularly as they affect the manner in which the Remote Procedure Calls (RPCs) made by the multitude of clients on a typical network need to be carried out.
Currently, in object-oriented distributed client/server computing environments, in order for client programs to initiate communication with and use an application defined in any one of the available services, which typically are located on a remote server, there are two different method invocations (i.e, RPCs) that are used. Each will now be described. The first type is called “static method invocation.” It requires the pre-generation of client side proxies/stubs based on its Service Interface Definition document during assembly and deployment phases of the distributed client's life cycle. The second type is called “dynamic method invocation.” It requires that the client applications be written using a given set of application programming interfaces (APIs) for dynamic method invocation in accordance with approved technique provided for with respect to each service to be utilized (e.g., in COBRA, its Dynamic Invocation Interface or DII must be used). These dynamic interfaces allow the clients to go and look up the service interface definition document dynamically and build each method request before invoking it.
Static method invocation, which is well-known, generally requires the following steps:                1. Generate the language level interface class from the Service Definition Interface.        2. Use the interface class generated in Step 1 in the client program environment in order to write/compile the client program.        3. Generate any needed language level client proxies/stubs for each of the distributed services being used within a client side program.        4. Package the generated client proxies/stubs for each service along with its interface class with the client program and run it.        
Although static method invocation requires many manual setups during development, assembly and deployment, it is used most often due to its relatively high performance (and therefore very short user delays) during runtime. But when the distributed service definition interface changes, which happens with some regularity in a changing computer environment, regeneration and preparation in order to use the new interface must be accomplished once again. This makes it necessary for the network administrators (or other computer support personnel responsible for maintaining the enterprise's network) to redeploy or otherwise update the affected client applications on the individual workstations or other end-user computers. Although such updating can now often be done remotely in a distributed computing environment, it still takes considerable time. Usually, every computer containing an affected client application must be accessed and updated, usually over lunch, after hours or on week-ends, to avoid inconveniencing end users. Such updates must often be scheduled to minimize disruptions. Hence, making such updates to all computers on a network represents a fairly major expense and is a bottleneck to maintaining applications on a network in an up-to-date state.
Dynamic method invocation, which is also well-known, attempts to solve this problem with deploying and using updated SIDDs. It generally requires the following steps:                1. Publish the Service Definition Interface information into an interface repository, which is typically maintained on one of the network servers.        2. Use the application program interfaces (APIs) provided for in approved dynamic method invocation interface APIs to exploit the distributed services dynamically inside the client program.        
Dynamic method invocation requires no client side set up, packaging or deployment. But, it puts a heavy burden on the client-side programmer to write method invocations using the dynamic invocation interfaces. Also, dynamic method invocation suffers from performance problems during runtime. This is due to the time it takes on the part of the client program to retrieve each of the service interface definitions and to build thereafter each method request before its invocation. The end computer users may experience a longer delay whenever a request is made. Such delays can incrementally impair user productivity as users wait for their responses. Also, as a network's overall performance is improved, these delays become more noticeable and therefore more of an issue.